Method for controlling access to protected content

ABSTRACT

A method is disclosed for controlling access by use of an operating system service to content that is to be protected from unauthorised access. The method includes the steps of, for an operating system service which can enable unauthorised access to protected content, modifying the operation of said operating system service to restrict or deny access to the protected content.

[0001] The present invention relates to a method for controlling accessto protected content. The present invention has particular relevance foroperating system (OS) security and to preventing access to OS servicesthat would otherwise directly or indirectly enable unauthorised accessto Digital Rights Management (DRM)-protected content.

[0002] If there is to be a viable commerce based upon the electronicdistribution of valuable multimedia content (such as for examplereports, images, music tracks, videos, etc.), then there must be somemeans of enforcing and retaining copyright control over the electroniccontent.

[0003] There is now emerging a set of hardware and software solutions,generically known as digital rights management (DRM) solutions, that aimto provide this copyright control while, to a varying degree, alsoenabling new commercial methods suited to the Internet and electronicdelivery. Common to virtually all these solutions is the requirementthat the multimedia content be distributed within a persistenttamperproof encryption wrapper (the idea being that a million copies ofencrypted content is no more valuable than one). Very simply, DRM worksby carefully providing the consumers of this encrypted content withsecret decryption keys that provide temporary access to the content forsome controlled purpose, e.g. viewing, printing, playing, etc. withoutever providing access to the raw decrypted content that could be usedfor unauthorised reuse or redistribution.

[0004]FIG. 1 illustrates schematically an overview of how typical DRMsystems work. Referring to FIG. 1, a “publisher” of digital contentseals their digital content, buffers or streams within a layer ofencryption and digital signatures into a DRM-encrypted content format102. The encryption makes it difficult for malicious consumers to obtainaccess to the raw decrypted content (and make unauthorised copies forredistribution). The digital signatures prevent malicious consumers orhackers from tampering with the encrypted content (perhaps to pass offthe content as their own or to distribute for free content that normallyhas to be paid for) by enabling the DRM system to detect the smallestchange to the encrypted content. The DRM-encrypted content 102 can thenbe delivered to consumers via any electronic distribution medium 104,e.g. web, ftp, email, CD-ROM, etc. The publisher need not worry aboutprotecting the DRM-encrypted content 102 in transit to the consumersince it is inherently protected by its encryption layer and digitalsignatures.

[0005] Less sophisticated DRM systems sometimes bundle individualconsumer access rights with the content, either within the encryptionlayer or at least protected by the digital signatures. The advantage ofbundling rights with the content is that the consumer can obtain boththe content and the rights at the same time. Disadvantages includeextreme inflexibility in the rights management policies that can beimplemented and an enormous versioning problem (since there needs to bea separate version of the encrypted content 102 for each consumer and anew version of the encrypted content whenever the rights change).

[0006] More sophisticated DRM systems deliver the rights separately fromthe content (from a DRM server 108). The rights are encoded in someelectronic format 110 (i.e. electronic “rights”) and specify thepermitted relationship between consumers and DRM-encrypted content sets(and subsets), e.g. which content the consumer can access, what they arepermitted to do with it (e.g. printing), and for how long.

[0007] A specialised viewer (the DRM client 106) resident on theconsumer device is required to obtain, manage and interpret the rights,temporarily decrypt the encrypted content and view/play it within asecure environment (so that the consumer cannot obtain access to the rawdecrypted content or the decryption keys) subject to the restrictionsimplied by the consumer's rights (e.g. view but do not print adocument). The DRM server 108 is responsible for issuing rights torequesting DRM clients 106. Current DRM systems typically issue rightsto authenticated consumers at the time of purchase (or grant) and therights are transferred to permanent storage on the consumer device 106.The DRM server 108 plays no further role in the ongoing use of thoserights.

[0008] A non-limiting description of several terms used herein will nowbe given to aid the understanding of the present invention.

[0009] In general, “rights” can be thought of as an electronicdescription (explicit or by implication) of the association betweenconsumers (or consumer devices) and DRM-protected content sets. Rightscan optionally specify means of identifying the consumer (or consumerdevice) to which the rights “belong”; means of identifying the contentsets and subsets to which the rights apply; encryption keys andchecksums (cryptographic or otherwise); and the specific access rightsgranted to the consumers (and/or their consumer devices) over thosecontent sets (e.g. whether or not the consumer can print a document, theduration of access, etc.). Rights can be encoded in any machine-readableform (e.g. parsable languages, specialised data structures, etc.) andare used internally by the DRM system to grant, deny or meter consumeraccess to encrypted content.

[0010] “Consumer device” is a device by means of which consumers accessDRM-encrypted content (e.g. view encrypted text or images, listen toDRM-encrypted music, watch DRM-encrypted video, etc) at the point ofconsumption.

[0011] “DRM client” refers to a specialised hardware and/or softwarecomponent operating on the consumer device which is responsible forverifying the authenticity of the consumer and temporarily decryptingthe encrypted content whilst it is being accessed and rendering thedecrypted content in a consumable form without allowing the consumer tomake copies of the decrypted content (e.g. displaying a DRM-protectedimage on the screen but protecting the image from screen grabbers). TheDRM client is basically responsible for looking after the contentowner's interests at the point of consumption.

[0012] “Operating system” (OS) refers to the (usually preinstalled)low-level software which handles the interface to peripheral hardware,schedules tasks, allocates storage, and presents a default interface tothe user when no application program is running.

[0013] “Application” refers to high-level software, often supplied bythird parties, that sits above the OS. Application software uses theservices of the OS to indirectly interface to the hardware devices andto other software programs running on the computing device, withoutrequiring specific low-level knowledge of those devices or softwareprograms. Application software usually provides the end user withhigh-level services such as word processing, spreadsheets, web browsing,etc.

[0014] “Process” refers to a part of a running software program or othercomputing operation that performs a single task. A modern multi-taskingOS is capable of running multiple processes that, to the end user, givethe appearance of running concurrently. An example of a process would bea web browser or a word processor application. Multiple instances of thesame process can often (though not necessarily always) be run at thesame time.

[0015] “Thread” refers to a portion of a process that can runindependently of and concurrently with other portions of the process. Ina modern OS, a process is often made up of multiple concurrentlyexecuting threads.

[0016] “Virtual memory” refers to a key feature of modern operatingsystems which provides applications with access to amounts of memory inexcess (typically far in excess) of the physical memory available on theconsumer device. This is achieved by swapping “virtual” memory areasbetween physical memory and permanent storage devices (e.g. hard disks).

[0017] “Loadable modules” refers to the components into which an OS isdivided and which provide specific low-level services (e.g. fileinput/output, network communications, etc.) via defined entry points.Application software loads these modules into virtual memory and invokesthese services by calling into entry points. These modules may be sharedbetween processes in order to conserve virtual memory.

[0018] “Kernel code” refers to specialised OS modules that are invokedby loadable modules to invoke lower-level functionality, functionalitythat is typically (but not always) not directly accessible toapplication software. Kernel code is responsible for, amongst otherthings, providing a uniform interface to the wide variety of third partyhardware devices (e.g. disk drives, sound cards, etc.) supported bymodern computer devices.

[0019] “Device driver” refers to a special software program which iscapable of operating within the kernel environment and capable ofdirectly manipulating the low-level hardware components that make up thecomputing device (e.g. memory, video memory, disk drives, etc.)

[0020]FIG. 2 illustrates schematically how the various componentsdefined above fit together within a typical consumer device running amodern OS. A consumer device generally has application software whichtypically provides high-level interaction between a user and the deviceand its peripherals. Application software includes, but is not limitedto, DRM client 202 a, web browser 202 b, spreadsheet 202 c and otherapplications 202 d. Depending upon the needs of a particularapplication, loadable modules are loaded to provide low-level services,(e.g. file i/o (input/output), network communications etc.). Loadablemodules include memory services 204 a, audio services 204 b, graphicsservices 204 c, and other services 204 d. To provide their services, theloadable modules invoke specialised kernel modules that provide accessto hardware that is not directly accessible to application software. Thekernel modules include virtual memory device driver 206 a, audio driver206 b, video driver 206 c, and other device drivers 206 d. These driversprovide access to hardware such as physical memory 208 a, sound card 208b, display 208 c and other hardware or peripherals 208 d. Thecombination of the kernel loadable modules and the device driverscomprises what is generally understood to be the device's operatingsystem (OS).

[0021] In practice the dominant client device at present is some form ofpersonal computer running a general purpose end-user OS such as Windows(or any of its variants), MacOS, UNIX, etc. The fact that these OS havebeen specifically designed to be open and extensible (in order tosupport third party application software and peripheral hardwaredevelopment) makes it very difficult to build secure DRM clientsoftware.

[0022] Some manufacturers claim to have developed hardware DRM clients,generally in the form of specialised chips with on-board cryptographicfunctions, tamper-resistant storage, trusted clocks, etc. Theimplication is that DRM hardware is inherently more trustworthy and lessvulnerable to tampering than DRM software. This is true in a limitedsense but misleading since the DRM hardware must ultimately communicatewith application-level software to display text or images or to playaudio or video. The old truism that “a chain is only as strong as itsweakest link” is particularly relevant here and the present invention isas relevant to “hardware” DRM solutions as to software DRM solutions.

[0023] One specific problem posed to DRM client implementers by theinherently insecure nature of the client OS relates to the fact that thedecrypted content must ultimately be provided to the consumer. Thisoften involves the DRM client handing off temporarily decrypted contentto OS subsystems that were never designed for security. For example, inthe case of text, images and video the decrypted content is drawn pixelby pixel to the video memory of the consumer device and then to thedisplay device, where it is immediately vulnerable to determinedhackers. On most computers the video memory is a shared resource, easilyaccessible to other software applications running on the same computer.There are a wide variety of “screen grabbers”, some of which are builtinto the OS, which can at any time recover a pixel-by-pixel copy of thecomputer screen.

[0024] Another problem is that at some point the DRM client must handoff temporarily decrypted content to a separate software viewercomponent, e.g. a HTML renderer or audio codec, so that it can bepresented to the consumer. The interface between the DRM client and theviewer component may not always be secure. For example, it may be thecase that the decrypted content must be written to the computer's diskbefore it can be loaded by the viewer component. While the decryptedcontent is on the disk, it is vulnerable to discovery and duplication byhackers.

[0025] According to a first aspect of the present invention, there isprovided a method for controlling access by use of an operating systemservice to content that is to be protected from unauthorised access, themethod comprising the step of: for an operating system service which canenable unauthorised access to protected content, modifying the operationof said operating system service to restrict or deny access to theprotected content.

[0026] Thus, in one preferred embodiment, the present invention providesa method for patching or otherwise modifying an OS kernel so that adigital rights management client can prevent access to OS services thatwould otherwise directly or indirectly enable unauthorised access toDRM-protected content. This is particularly useful for “retro-fitting”low level security to an otherwise insecure operating system.

[0027] The step of modifying the operation of said operating systemservice may comprise the steps of: obtaining an address of an entrypoint of the operating system service, and placing, starting at theentry point address, an instruction such that, when the instruction isexecuted, substitute code is executed, the substitute code operating torestrict or deny access to the protected content. The instruction may bea jump instruction.

[0028] The method may comprise the step of, after the substitute code isexecuted, returning the operating system service to its unmodifiedstate. The step of modifying the operation of said operating systemservice may comprise the step of, prior to placing of the instruction,copying to a buffer a service preamble starting at the entry pointaddress and wherein the step of returning the operating system serviceto its unmodified state includes the steps of restoring the servicepreamble that was copied to the buffer to its original position at theentry point address and returning control to the entry point address.Alternatively, the step of modifying the operation of said operatingsystem service may comprise the step of, prior to placing of theinstruction, copying to a buffer a service preamble starting at theentry point address and wherein the step of returning the operatingsystem service to its unmodified state includes the steps of executingthe service preamble from the buffer to which it was copied and thenreturning control to a point just after the place from which the servicepreamble was copied.

[0029] The step of modifying the operation of said operating systemservice may comprise the step of: replacing an address of an entry pointof the operating system service in a trap dispatcher table with anaddress of an entry point of substitute code, the substitute codeoperating to restrict or deny access to the protected content.

[0030] The operating system service may be modified before anyapplication processes are loaded. An initialisation module may be loadedbefore any application processes have been loaded, the modifying stepbeing based on instructions in the initialisation module. Theinitialisation module is preferably loaded into every applicationprocess.

[0031] Some mechanism may be employed to propagate patches or othermodification across all (or at least all relevant) operating systemservices.

[0032] Thus, there may be a loadable module that has initialisation codewhich when executed causes said modifying step to take place andclean-up code which when executed causes said modifying step to beundone, the method comprising the step of loading the loadable moduleinto every running application process.

[0033] The step of loading the loadable module may be carried out as aresult of the execution of another operating system service.

[0034] The act of loading the loadable module into a running applicationprocess may cause the initialisation code to be executed. The act ofunloading the loadable module from a running application process maycause the clean-up code to be executed.

[0035] As an alternative, the method may comprise the step of a digitalrights management client operating via an inter-process communicationmechanism to cause the loadable module to execute its initialisationcode and clean-up code within the context of each running applicationprocess.

[0036] The modification of the operating system service may function toprotect, from screen grabbing, at least a visible area of an imagedisplayed on a screen.

[0037] A virtual file system may be implemented that can be used tocommunicate decrypted content to a renderer without exposing thedecrypted content to unauthorised access via a local file system.

[0038] The method may comprise the steps of: passing to a renderer afilename for a virtual file; requesting by the renderer access to thefile; and, routing the renderer's access request via the virtual filesystem to a buffer containing the protected content. The step ofdecrypting the protected content may be carried out before placing theprotected content in the buffer. As an alternative, the method maycomprise the step of placing encrypted content in the buffer, themodified operating system service obtaining a decryption key to decryptthe encrypted content on demand.

[0039] The method may comprise the step of implementing a secure filesystem by which only trusted invocations of the operating system arepermitted to decrypt encrypted files stored within an encrypted portionof the secure file system. Said encrypted portion of the file system maycontain protected content and associated licensing information.

[0040] The method may comprise the steps of: establishing guard pointsto indicate which processes, threads, and/or windows are trusted; and,restricting execution of the operating system service only to thetrusted processes, threads, and/or windows.

[0041] Operation of the operating system service may be modified by useof for example a device driver, a file system hook, or an installablefile system module.

[0042] So-called upstream and downstream patches may be applied by amalicious user. These can be used to allow access to the protectedcontent, which plainly is not desired.

[0043] Thus, the method preferably comprises the step of inspecting theoperating system service for the presence of a downstream patch or hook.The step of inspecting the operating system service may include thesteps of comparing a snapshot of the operating system service with asnapshot of the operating system service obtained during operatingsystem start-up.

[0044] The method may comprise the step of detecting an upstream patchor hook by determining whether a patched operating system service entrypoint still points to substitute code installed by a digital rightsmanagement client.

[0045] The method may comprise the step of detecting an upstream patchor hook by removing and then reinstalling a patch installed by a digitalrights management client.

[0046] According to a second aspect of the present invention, there isprovided a method for controlling access by use of an operating systemservice to content that is to be protected from unauthorised access, themethod comprising the steps of: running an untrusted applicationroutine; and, prior to the application routine using an operating systemservice that would enable unauthorised access to content which is to beprotected, determining whether use of said operating system servicewould cause said operating system service to access said content and, ifso, restricting or denying the operating system service access to saidcontent.

[0047] This second aspect relates to an operating system which isalready provided with the functionality described above, i.e. it is notnecessary to “retro-fit” the low level security described herein;rather, that low level security is already provided.

[0048] Preferred and optional features of the second aspect are similarto at least some of the preferred and optional features of the firstaspect.

[0049] The present invention also relates to a computer programcontaining program instructions for causing a computer to perform amethod as described above. The computer program may be embodied in adigital rights management client.

[0050] Embodiments of the present invention will now be described by wayof example with reference to the accompanying drawings, in which:

[0051]FIG. 1 illustrates schematically a DRM overview;

[0052]FIG. 2 illustrates schematically the various hardware and softwarecomponents within a typical consumer device running a modern OS;

[0053]FIG. 3A illustrates schematically execution of a kernel servicethat has not been patched;

[0054]FIG. 3B illustrates schematically an example of a kernel patchingprocess in accordance with an embodiment of the present invention;

[0055]FIG. 3C illustrates schematically an example of execution of akernel service after patching in accordance with an embodiment of thepresent invention;

[0056]FIGS. 4A and 4B illustrate schematically an example of trappatching under MacOS in accordance with an embodiment of the presentinvention;

[0057]FIG. 5A illustrates schematically application processes runningagainst unpatched kernel services;

[0058]FIG. 5B illustrates schematically the propagation of patchesbetween processes by the forced loading of an example of a patchingloadable module according to an embodiment of the present invention;

[0059]FIG. 6 illustrates schematically an example of a method ofprotecting video memory from screen grabbing according to an embodimentof the present invention;

[0060]FIG. 7 illustrates schematically a virtual file system and theconcept of establishing guard points on trusted processes, threadsand/or windows in accordance with an embodiment of the presentinvention;

[0061]FIG. 8 illustrates schematically an example of use of a devicedriver to perform interrupt-based kernel-level patching;

[0062]FIG. 9 illustrates schematically examples of the use ofinstallable file system hooks in accordance with an embodiment of thepresent invention;

[0063]FIG. 10 illustrates schematically examples of DRM installable filesystem modules and the concept of establishing guard points on trustedprocesses, threads and/or windows in accordance with an embodiment ofthe present invention; and,

[0064]FIG. 11 illustrates schematically upstream and downstreampatches/hooks and examples of DRM patching/hooking countermeasures inaccordance with an embodiment of the present invention.

[0065] In the following, particular reference will sometimes be made tothe Windows (and Windows related) and the Mac operating systems.Nevertheless, it will be appreciated that many embodiments of thepresent invention are applicable to a wide variety of other operatingsystems.

[0066] According to one embodiment of the present invention, an OSkernel is patched (i.e. modified) so that a DRM client can “police”access to OS services that would otherwise directly or indirectly enableunauthorised access to DRM-protected content. An example of such an OSservice is the set of graphics primitives offered by the graphicalsubsystem GDI32 on the Win32 (i.e. Windows 32-bit) operating system,e.g. BitBlt, StretchBlt, etc. These kernel primitives allow applicationdevelopers to rapidly copy images to and from video memory and thereforecan be used (and are used) to easily develop “screen grabbers” that copythe contents of the screen to a buffer which can then be saved to disk.If the DRM client is rendering DRM-protected images on the consumerdevice, it must somehow defend against unauthorised “grabbing” of theseimages. This can be achieved by patching the OS services, such asBitBlt, StretchBlt, etc., such that the DRM client can first checkwhether they are being used to access images rendered by the DRM clientand, if so, to substitute the protected image with something else (e.g.a warning message). If the OS services are being used for purposes notinvolving the DRM client or DRM-protected content, then the patched OSservices are executed exactly as if they had not been patched.

[0067] Although a concrete example has been given in the context ofgraphics primitives on Win32 platforms, it will be appreciated that thegeneral concept of patching OS kernel services to secure DRM-protectedcontent can be applied to any relevant OS kernel service. This techniqueprovides an extremely powerful means of providing security at a lowlevel to operating systems that were not originally designed to besecure.

[0068] Most, if not all, modern operating systems appear to applicationsoftware developers as a set of loadable modules, each of which providesa set of specific low-level services (e.g. file input/output, networkcommunications, etc.) via defined entry points. Application softwareloads these modules into virtual memory and invokes these services bycalling into the entry points (i.e. effectively transferring CPUexecution to the address of the entry point). These modules may beshared between processes in order to conserve virtual memory.

[0069]FIG. 3A illustrates schematically execution of a kernel servicethat has not been patched. Referring to FIG. 3A, a process invokes akernel service at 310 a by calling the entry point of the service. Thekernel service code is executed at step 310 b. After completion of theexecution of the executable code, control is returned to the invokingprocess at step 310 c.

[0070] As described above, the loadable modules can be patched to enablethe DRM client to alter the operation of these services to protectDRM-protected content. As noted above, the DRM client is responsible for(temporarily) decrypting and rendering DRM-protected content to theoutput devices of the consumer device. Before the decrypted content isrendered, the DRM client or some other device patches any OS kernelservices that are considered to present a possible threat. FIG. 3Billustrates schematically an example of a preferred kernel patchingprocess.

[0071] Referring to FIG. 3B, the DRM client executes the followingsequence of operations for each kernel service it needs to patch:

[0072] 1. Load the OS loadable module exporting that service into theDRM client's process space (if it is not already loaded).

[0073] 2. Obtain the address of the entry point of the service to bepatched.

[0074] 3. Copy a number of bytes from the beginning of the service entrypoint to a shared buffer at step 320 a. The number of bytes issufficient to contain a standard “jump” instruction (normally an op codeplus a few bytes of address or offset) or a standard “trap” instruction(i.e. an instruction that throws a software interrupt which can beintercepted by a trap handler which transfers execution to a newlocation, which is effectively a jump). These bytes are also referred toas the “service preamble”.

[0075] 4. Replace the copied preamble bytes at the beginning of theservice entry point with a “jump” instruction pointing at an in-processbuffer containing the executable patch code for the OS service at step320 b.

[0076] As shown in FIG. 3C, after this patched service entry point isexecuted at step 320 c by a process invoking the patched kernel service,control is transferred to the patch code in the shared buffer, step 302d. At step 320 e, the patch code performs its checks (e.g. checking thatthe video memory being accessed by a graphics service does not containDRM-protected imagery) and then optionally executes the original kernelservice (if required and permitted by the DRM client). As well asperforming checks, the patch code can perform arbitrary operations, e.g.replacing DRM-protected images with a warning message if appropriate.

[0077] As shown at step 320 f, the original service can, if permitted,be executed by either (a) copying back the service preamble andtransferring control to the original service entry point or (b)executing the preamble from the buffer to which it was copied and thentransferring control to the remainder of the original service, i.e. theinstruction after the removed preamble code. The latter approach isviable if the copied preamble can be determined to contain complete CPUoperations (which may span several bytes).

[0078] When the DRM client is not handling decrypted content (andtherefore has nothing to defend), it can reverse the patching steps toun-patch the OS services and return the OS to normal insecure operation.

[0079] Each of the steps described above makes use of standard OSservices which are available on all modern operating systems, e.g.loading OS modules, obtaining the address of service entry points, etc.If a given OS loadable module contains multiple services that requirepatching, then the patching and execution steps described above can berepeated without reloading the OS module.

[0080] Whilst the exact details of each operation will of course varybetween different operating systems, the concept and methodologydiscussed herein of patching the OS kernel services to enable the DRMclient to defend DRM-protected content is widely applicable.

[0081] An example of the minor modifications required for differentoperating systems can be appreciated by comparing the Macintoshoperating system, MacOS, (for versions prior to MacOS X) to Windows. Themeans by which applications access OS kernel service entry points isslightly different in each of these operating systems. FIGS. 4A and 4Billustrate schematically an example of trap patching under MacOS.

[0082] Referring first to FIG. 4A, under MacOS, applications access OSkernel service entry points by looking up an offset that identifies theparticular entry point, loading this offset into a pre-defined location(step 402 a), and firing a software interrupt (known as a “trap”) (step402 b). A separate trap dispatcher handles the interrupt and looks upthe offset set by the calling process (step 402 c). This offset is usedto look up the address of the desired kernel service from a tablemapping offsets to service entry point addresses. The trap handler thentransfers CPU execution to this address.

[0083] Referring to FIG. 4B, standard MacOS services enable “trappatching” whereby application processes (or special processes executedat OS start-up) can load a code fragment (the patch) into global memory(step 404 a) and substitute the address of this patch in place of theactual kernel service entry point address in the trap dispatcher'stable(step 404 b). Thus, when the actual kernel service is loaded (step404 c), and a software interrupt is fired (step 404 d), the trap handlertransfers execution (step 404 e), to the patch code. The patch code isthen executed (step 404 f) in place of the kernel service (although itcan itself call the kernel service, as shown in step 404 g), resultingin the same ability to patch kernel services with code that protectsdecrypted DRM content from other processes.

[0084] Whilst the details may differ between operating systems, one ofordinary skill in the art will have sufficient knowledge of modernoperating systems to appreciate these differences.

[0085] If the patched OS module is shared by all other processesexecuting on the consumer device, then patching it within the context ofthe DRM client's process will cause it to be patched for all otherprocesses. This is the case, for example, in simpler operating systemssuch as Windows 95 and 98.

[0086] If the patched OS module is not automatically shared by all otherprocesses executing on the consumer device, then the patches arepreferably propagated to those other processes. Otherwise, those otherprocesses may allow access to the unprotected OS services that opensecurity loopholes to the DRM-protected content.

[0087]FIG. 5A illustrates schematically applications running againstunpatched kernel services. Each process 502 a, 502 b, 502 c has its ownassociated kernel service (504 a, 504 b and 504 c respectively) which isnot modified when another process patches its kernel service. On someoperating systems, it may not be possible to patch OS kernel servicesfor all processes from an already running process (in particular the DRMclient) because of the use of “protected memory”. Modern operatingsystems typically attempt to assign each process a completelyindependent region of virtual memory that is invisible and inaccessibleto all other processes. This is an improvement over earlier operatingsystems where one process could accidentally overwrite memory from anyother process, usually crashing the process or the entire OS.

[0088] An example of the difficulty this causes for patching kernelservices is in MacOS where patching traps from a running process onlyaffects the process which patched the trap (because each process has itsown copy of the trap table which maps service offsets to service entrypoint addresses).

[0089] If it is not possible to patch OS kernel services for allprocesses from an already running process, then the OS kernel servicescan be patched from special modules loaded during OS start-up, i.e.before any application processes have been loaded. Most modern operatingsystems have specialised software modules that are loaded during thestart-up of the OS (typically after switching on the consumer device orafter a reboot). These modules are typically used to initialise thehardware and software components of the consumer device, e.g. networkdevices and various drivers. Because they are executed prior to anyapplication software, they can often make (global) changes to the kernelthat are automatically inherited by application software processeslaunched subsequently. For example, on MacOS these start-up modules,known as “inits” or “extensions”, can install global trap patches thatare inherited by all processes running on the consumer device. Thisenables the DRM client to patch and police the relevant kernel services,thus preventing other process from obtaining unauthorised access to thedecrypted DRM-protected content.

[0090] As mentioned above, if the patched OS module is not automaticallyshared by all other processes executing on the consumer device then thepatches are preferably propagated to those other processes. Otherwise,those other processes may allow access to the unprotected OS servicesthat open security loopholes to the DRM-protected content.

[0091] An example of an operating system in which patched loadable OSmodules are not shared between processes is Windows NT. Under WindowsNT, the loadable modules that implement kernel services are initiallyshared between processes (to conserve virtual memory) but if they are tobe modified, for example by the patching methodology described above, acopy of the unmodified loadable module is made and it is this copy thatis modified. The other processes continue to share the unmodifiedloadable module. This handling of shared loadable modules is known as“copy-on-write” and is very common in modern operating systems.Unfortunately, it prevents patches made by the running DRM clientprocess from being automatically propagated to other processes.

[0092] On modern operating systems, typically there are OS services thatcause an identified module to be loaded into every process. For example,Windows provides an OS service called SetWindowsHookEx that installs ahook function that can be used to monitor windowing messages. This hasthe side effect that the loadable module containing the hook function isloaded into every process running on the consumer device. It is almostalways the case on modern operating systems that loadable modules haveinitialisation and clean-up entry points that are called when the moduleis loaded into a process and unloaded from a process, respectively. Ifthis is not the case, then initialisation and clean-up code can beexecuted from the DRM client process using any inter-processcommunication (IPC) mechanism, or, lazily, based upon subsequentexecution of code by the process loading the module.

[0093] Thus, if necessary or desirable, code that performs the patching,as described above, is placed within a loadable module that is loadedinto every process, using an OS service such as for exampleSetWindowsHookEx or any other suitable means available to force theloading of a module into every process space for a given OS. FIG. 5Billustrates schematically the propagation of patches between processes.When the module is loaded into each process on the consumer device atsteps 506 a, 506 b, 506 c, its initialisation code performs thein-process patching operation as described above at steps 508 a, 508 b,508 c. In this fashion, the patches are propagated across all theprocesses executing on the consumer device. When the DRM client wishesto remove the patches, it reverses the process by which it caused thepatching module to be loaded into each process, e.g. by callingUnhookWindowsHookEx (the opposite of SetWindowsHookEx). As each processunloads the patching module, its clean-up entry point is called, whichremoves the patches from the OS modules of each process.

[0094] The techniques described above can be used to protectDRM-protected text and images (and video frames) from screen grabbingapplications. Almost all application software accesses video memoryindirectly, via a rich set of graphics services provided by the OS. Thisis for convenience, since application developers are presented with alarge library of reusable graphics code, and also because of the chaosthat would result if applications were not protected from overwritingeach other's video memory. Modern OS graphics services typicallyimplement a windowing concept whereby applications are issued withnotional “windows” (actually high-level data structures managed by theOS) into which they can draw. The OS graphics service looks afterordering these windows with respect to each other, redrawing them whenthey are revealed by the movement of other windows, resizing them, etc.

[0095]FIG. 6 illustrates schematically an example of a method ofprotecting video memory from screen grabbing according to the presentinvention. The DRM client, in the case of DRM-protected text, images(and video frames), will be rendering this content (directly or viathird party software components) to one or more of these “windows”.Before it does so it adds the relevant windows to a list of “protectedwindows” maintained in a location accessible to all processes (e.g. inshared memory, on disk, etc.). At step 602, the DRM client then patchesall OS services 604 a, 604 b, 604 c that are capable of accessing thegraphical images being rendered within these protected windows (e.g. theGetPixel OS service on Windows that recovers an individual pixel valuefrom a nominated window and that could be used repeatedly toreconstitute the window's image).

[0096] At step 606, when the patched OS services are invoked, thepatches look up the window to which they are being applied and, if it ison the list of protected windows, perform some defensive action. Forexample, the underlying graphics service can be applied to an artificialwindow containing some replacement graphic (using cropping and tiling tofit to arbitrarily sized windows as necessary), but any other actionthat defends the DRM-protected graphical images without adverselyaffecting the operation of the OS would suffice. If the window is notprotected, the patches simply pass execution to the underlying OSservice. When the DRM client is finished with a protected window, i.e.it is no longer using it to display DRM-protected content to the enduser or the window has been closed, it can remove the window from thelist of protected windows. If the window is the last window in theprotected window list, the DRM client can safely remove the OS graphicsservices patches (if the patches are being applied dynamically, i.e.from the running DRM client process rather than for example at OSstart-up).

[0097] It should be noted that on most modern operating systems, it ispossible for the patch code to calculate which portions of a protectedwindow are visible and which are obscured by another window (generallyby traversing the window hierarchy in z-order, i.e. the order in whicheach window is layered above each other). By calculating a clip regioncorresponding to the obscured areas (most OS graphics kernel servicesprovide means of calculating complex composite clip regions), it ispossible to replace the protected image with a replacement image withoutpreventing screen grabbing of unprotected areas. This is a considerableimprovement over simply preventing grabbing of the entire screen orwindow.

[0098] The techniques described above can be used to implement a virtualfile system whereby the DRM client can pass DRM-protected content tothird party viewer components and applications without exposing thedecrypted content on the consumer device's local file system (from whichit could be recovered by hackers). The DRM client protects the encryptedcontent as far through the rendering and viewing/playing process aspossible. It is not sufficient for the DRM client to simply decrypt thecontent and pass the decrypted content onto an insecure third partyviewer (such as a web browser or audio player) since the decryptedcontent can easily be recovered from the third party viewer (forexample, by examining the browser cache or clicking File . . . Save Ason an audio player). To be secure, the DRM client preferably provides asecure viewing environment, i.e. it provides for a secure viewer/playerfor each supported media type. Since building secure viewer/players foreach supported media type is expensive, DRM vendors typically use thirdparty viewer/player components to ease this task. Unfortunately, many ofthese viewer/player components expect the decrypted content to be passedto them via the local file system (i.e. from disk), which represents amajor security loophole. If the DRM client writes the decrypted contentto disk so that it can be loaded into a third party viewer/player then ahacker can easily intercept the decrypted content at the time it iswritten to disk. Simply trying to hide the decrypted content by usingtemporary filenames and obscure locations (as is presently done in somesystems) is ineffective since there are many freely available utilitiescapable of monitoring the local file system.

[0099] The OS kernel patching techniques described above can be used toimplement a virtual file system by which the DRM client can decrypt theDRM-protected content to an in-process memory buffer which is accessibleonly to the trusted third party viewer/player component via patchedkernel file input/output (i/o) services.

[0100]FIG. 7 illustrates schematically an example of a virtual filesystem and the concept of establishing guard points on trustedprocesses, threads and/or windows. An example of a sequence ofoperations which can be performed to provide a virtual file system andguard points is as follows:

[0101] 1. The DRM client 702 decrypts the content into an in-processmemory buffer 704.

[0102] 2. The DRM client 702 patches the OS kernel file i/o services 706used by the trusted third party viewer/player component (this may bedone at OS start-up if it cannot be achieved dynamically from a runningprocess; see the discussion on propagating patches above).

[0103] 3. The DRM client invents a filename that does not exist on thelocal file system. The DRM client passes the filename to the trustedthird party viewer/player component 708.

[0104] 4. The trusted third party viewer/player component 708 opens the“virtual” file using the invented filename (which does not actuallyexist on the local file system). The patched kernel file i/o servicesdetects attempts to read, seek or write from/to the “virtual” file androutes those requests to read, seek or write from/to the DRM client'sin-memory buffer 704.

[0105] 5. The DRM client and the patched kernel file i/o servicescooperate to ensure that the virtual file is only being accessed fromtrusted processes, threads and/or windows (so that other “unauthorised”processes, threads and/or windows cannot access the virtual file whilethe decrypted buffer exists even if they can obtain the virtualfilename). This is achieved by setting (step 710) and removing (step712) “guard points” on trusted processes, threads and/or windows withinwhich trusted viewer file i/o requests are routed to the decryptedcontent stored in the in-process memory buffer 704. This setting andremoving guard points on trusted processes, threads and/or windows isimportant since otherwise an untrusted process could be used by a hackerto obtain access to the decrypted content by simply obtaining thefilename of the virtual file and using normal file i/o services to readthe decrypted virtual file. Setting and removing guard points is one wayof keeping track (in a secure manner) of which processes, threads and/orwindows are trusted at a given point in time by the DRM client.

[0106] 6. When the trusted third party viewer/player no longer needsaccess to the virtual file, the DRM client can remove the in-processmemory buffer containing the decrypted content and remove the virtualfile from the list of such files handled by the patched kernel file i/oservices.

[0107] This arrangement allows the DRM client to (i) use third partyviewer/player components that expect input files without exposingdecrypted content to the local file system (from where it can easily behijacked by hackers); (ii) transparently load encrypted content intothird party viewer/player components not originally intended to accessencrypted content (e.g. encrypted Java into a standard browser JavaVirtual Machine); and (iii) detect and prevent untrusted processes orthreads from writing DRM-protected content to the local file system.

[0108] A useful modification to the virtual file system is for the DRMclient to simply place the encrypted content into its in-process sharedmemory buffer and for the patched file i/o services to obtain decryptionkeys from the DRM client and decrypt the content on demand, as it isread by the trusted third party viewer/player. This has the advantage ofreducing the amount of time for which the content is in its vulnerabledecrypted state.

[0109] Device drivers are special software programs capable of operatingwithin the OS kernel environment and of directly manipulating thelow-level hardware components that make up the consumer device (e.g.memory, video memory, disk drives, etc.). Because of the high processorprivilege levels within which they execute, device drivers can perform anumber of functions not available to application processes that canconsiderably improve the reliability of the patching process(es)described above. Depending upon the OS, there are a number of welldocumented ways a high-level application process (such as the DRMclient) can communicate with a device driver (and vice versa).

[0110] Thus, a cooperating device driver can be used to enhance the DRMclient patching process described previously. FIG. 8 illustratesschematically an example of use of a device driver to performinterrupt-based kernel-level patching.

[0111] There is a very small but finite risk that a given OS serviceentry point may actually be in the process of being executed whilst theservice preamble is being patched by the DRM client unless the preamblereplacement can be performed by a guaranteed atomic operation, i.e. onethat cannot be interrupted. On many operating systems, patching theservice preamble involves replacing it with a “jump” operation which istoo long to copy over the preamble in a single atomic operation. If anOS service entry point is executed whilst the service preamble is beingpatched, the results would be unpredictable but would probably result ina crash of the affected process or even the entire OS. Device driverscan hook hardware and software interrupts as part of their basiccapability of interfacing to physical devices and the low-level kernel.On most operating systems, there are very short (typically but notalways a single byte) operations that can generate a software interrupt.This operation can be copied over the service preamble in an atomicoperation. This can be used to implement a jump using a short operationthat can safely be patched over the existing service entry pointpreamble.

[0112] Thus, in an example, at step 802 the DRM client calls down to thedevice driver to register the jump address, associating it with theaddress from which the software address would be thrown. When the patchinterrupt is thrown (because the process has invoked the patched serviceentry point) at step 804, the device driver at step 806 intercepts theinterrupt, looks up the address from which it was thrown and theassociated jump address and then transfers control to that address, ineffect executing the jump to the DRM client's patch routine. Thisapproach has the additional advantage that it allows the DRM client topatch extremely short OS service preambles (the service preamble mayimmediately jump to some adjoining code, which requires very few byteson many operating systems).

[0113] On some operating systems, a privileged device driver is requiredto make the memory of the loadable module writeable so that it can bepatched. Whilst there are means of doing this directly from anapplication, they are usually difficult and potentially unreliable.

[0114] Some functionality required by DRM clients, such as installing afile system hook (see below), can only be implemented in the privilegedenvironment of a device driver.

[0115] The local file system on most modern operating systems isimplemented by kernel-level device drivers that sit between the hardwarestorage devices (e.g. hard disks, floppy disks, CD-ROMs, etc.) andapplication processes. The file i/o subsystem of the OS kernel providesa uniform, well-defined interface to these disparate storage deviceswhich enables application processes to read and write from/to thesedevices via the uniform interface without worrying about the precisedetails of each storage device. A common feature of the file i/osubsystems provided by modern operating systems is the ability toinstall a file system hook. A file system hook is a software functionthat can be installed into the file i/o subsystem such that it canintercept, monitor and modify or replace each low-level file i/ooperation. File system hooks are generally: (i) implemented sufficientlydeep within the file i/o subsystem that all higher-level file i/oservice requests are routed through them; (ii) required to run in aprivileged process (and therefore must usually be installed from, andimplemented within, a kernel-level device driver); and (iii) implementedin a hook chain in which multiple file system hooks can be installedwith the most recently installed hook being called first and(optionally) calling down into the next hook until (optionally) theoriginal file i/o service is called. Nothing requires a particular filesystem hook to call further hooks in the chain (or the original service)and most file system hooks can only detect the next hook in the chain.

[0116] In view of the above, installable file system hooks can be usedby DRM clients to improve OS security. FIG. 9 illustrates schematicallyexamples of such use of installable file system hooks in arepresentative OS.

[0117] 1. Patching the OS kernel. In some embodiments describedelsewhere herein, the kernel loadable modules are patched after they areloaded into virtual memory. These kernel loadable modules are actuallyloaded from special files on the local file system during OS start-up oron-demand by application processes. An alternative method of patchingthe kernel loadable modules is to use file system hooks to intercept thelow-level file i/o operations used when the kernel modules are beingloaded into virtual memory and to modify those operations so that whatis actually loaded into virtual memory is an appropriately patchedversion of the kernel loadable modules. This is a relativelystraightforward process since the internal format of loadable modules iswell documented.

[0118] 2. Virtual file system. By installing a file system hook, the DRMclient can effectively gain control over the file system. The routing offile system i/o to in-memory buffers containing decrypted contentdescribed above in connection with FIG. 7 with respect to the use of avirtual file system can be implemented by a file system hook 902 whichcan route trusted invocations of the file i/o services to the DRMclient's in-process memory buffer 904. The DRM client can establishtrusted invocations by only routing requests to the decrypted bufferbetween start and stop guard points set on trusted processes, threadsand/or windows. As noted previously, the setting and removing guardpoints on trusted processes, threads and/or windows is important sinceotherwise an untrusted process could be used by a hacker to obtainaccess to the decrypted content via the installable file system hook,simply by obtaining the filename of the virtual file and using normalfile i/o services. Setting and removing guard points is one way ofkeeping track (in a secure manner) of which processes, threads and/orwindows are trusted at a given point in time by the DRM client.

[0119] 3. Secure file systems. File system hooks can be used to routefile system i/o to an encrypted portion of the file system 906, withonly trusted invocations of the file i/o services (see above) being ableto transparently decrypt the files stored within the encrypted portionof the file system. Untrusted invocations of the file i/o services onlysee the encrypted files. Files stored in the encrypted portion of thefile system can be identified for example by some characteristic oftheir filenames, e.g. a certain root device. The encrypted portion ofthe file system could be used to store DRM-protected content andassociated licensing information.

[0120] It is noted that the local file system on most modern OS isimplemented by kernel-level device drivers that sit between the hardwarestorage devices (e.g. hard disks, floppy disks, CD-ROMs, etc.) andapplication processes. The file i/o subsystem of the OS kernel providesa uniform, well-defined interface to these disparate storage deviceswhich enables application processes to read and write from/to thesedevices via the uniform interface without worrying about the precisedetails of each storage device. Another common feature of the file i/osubsystems provided by modern operating systems is the concept ofinstallable file systems whereby support for new storage devices can beadded to a consumer device by simply installing new kernel-levelloadable modules that “plug into” the file i/o subsystem withoutdisturbing the uniform interface presented to application processes.These installable file system modules (IFS modules) need not actuallymake use of a real, physical device. For example, they can implementfile systems within RAM or within encrypted or compressed files residenton other file systems.

[0121] DRM clients can use installable file systems in a variety ofways, some of which are described below. FIG. 10 illustratesschematically examples of DRM installable file system modules and theprocess of establishing guard points on trusted processes, threadsand/or windows.

[0122] 1. Virtual file system. The virtual file system described abovecan be implemented by an IFS module since routing file system i/o toin-memory buffers or encrypted or compressed files within other filesystems is exactly what IFS modules are designed to do. IFS module 1002can route trusted invocations of file i/o services to either the DRMclient's in-process memory buffer 1004 or encrypted files residentwithin a conventional file system 1006. Provided the invocation wastrusted, the IFS module can optionally decrypt the content “on-the-fly”or, more simply, access a pre-decrypted buffer. The former would be moreappropriate for encrypted files resident within a normal file system,the latter for content resident within a DRM client buffer. The DRMclient can establish trusted invocations by only routing requests to thedecrypted buffer between start 1008 a and stop guard points 1008 b seton trusted processes, threads and/or windows. The setting and removingguard points on trusted processes, threads and/or windows is againimportant since otherwise an untrusted process could be used by a hackerto obtain access to the decrypted content via the IFS module, simply byobtaining the filename of the virtual file and using normal file i/oservices.

[0123] 2. Secure file systems. An IFS module can be used to route filesystem i/o to an encrypted portion of the file system, with only trustedinvocations of the file i/o services (see above) being able totransparently decrypt the files stored within the encrypted portion ofthe file system. Untrusted invocations of the file i/o services only seethe encrypted files. Files stored in the encrypted portion of the filesystem can be identified for example by some characteristic of theirfilenames, e.g. a certain root device. The encrypted portion of the filesystem can be used to store DRM-protected content and associatedlicensing information.

[0124] Some of the techniques used in the preferred embodiment of thepresent invention for retrofitting low level security to insecureoperating systems, such as patching low-level kernel service andinstalling file system hooks, are techniques that are known per se andare also available to an expert hacker. Thus, measures may be taken toprotect the DRM client from subversion by the very techniques the DRMclient is using to provide security.

[0125]FIG. 11 illustrates schematically upstream and downstreampatches/hooks and examples of DRM countermeasures. Patching low-levelkernel services and installing file system hooks are inherently similarin their vulnerability to countermeasures. In the case of patching, theDRM client inserts a patch stage 1103 between the kernel service entrypoint 1102 and the kernel service executable code 1104. It is possiblefor a hacker to have inserted a separate patch before the DRM patch wasinstalled (downstream patch) 1106 or to insert a separate patch afterthe DRM patch was installed (upstream patch) 1108 or both. The hackerpatches are known as downstream and upstream patches because, in theworst possible case, the execution flow from the service entry point isvia upstream patch(es) followed by DRM patch followed by downstreampatch(es) followed by the actual service executable code. In the case ofinstalling file system hooks, the hooks are generally installed in achain with the latest hook only knowing about the address of theprevious hook in the chain, which may be the address of the actual filesystem i/o service executable code. Again, a hacker could insert bothupstream and downstream hooks.

[0126] The threats to the DRM client of hacker-installed patches orhooks, and the means by which they can be detected and circumvented, arebroadly similar for patching or hooking, so the remainder of thisdiscussion uses terminology for patching with the understanding beingthat this discussion pertains to hooking as well.

[0127] DRM security is threatened by hacker-installed upstream anddownstream patches. In the case of upstream patches, the DRM patch willbe invoked by the upstream patch that is effectively masquerading as theinvoking trusted process, thread and/or window. If the DRM patch returnssecrets to the upstream patch, then security is compromised. Forexample, the DRM patch could be returning decrypted content from a filei/o read operation against the virtual file system as discussed abovewhich would then be passed back to the upstream patch which could, forexample, save it to disk.

[0128] In the case of downstream patches, the DRM patch may make use ofthe underlying kernel service executable code to perform its function.When a downstream patch is present, it is effectively masquerading asthe kernel service executable code and if the DRM patch passes it anysecrets then security is also compromised. For example, i-the DRM clienthas patched a graphical subsystem primitive that copies bitmaps from thescreen (e.g. CopyBits on the Mac) so as to protect the screen fromscreen grabbing, then it may actually use the underlying service toobtain the bitmap from the screen so that it can then modify that bitmapto exclude the protected windows. The downstream patch would then haveaccess to that bitmap prior to it being modified to exclude theprotected window and could, for example, save that bitmap to disk.Downstream patches are typically less dangerous to the DRM client thanupstream patches and can often be avoided entirely by simply not passingsecrets downstream.

[0129] Hacker-installed upstream and downstream patches are preferablydetected and neutralised. For example, referring to FIG. 11, at step1110, when first applying and subsequently executing a DRM patch, theDRM client can examine the code that is being patched for signs ofdownstream patches (e.g. unexpected code preambles or jumps to memory inunexpected locations, compared to other kernel services). If adownstream patch is detected then, depending upon the level of threat,the DRM client can deny service until the downstream patch is removed.

[0130] Alternatively, at step 1112, during OS start-up the DRM clientcan snapshot the kernel service (either the entire service or a limitedpreamble) for later use in downstream patch detection. The snapshotshould be placed as early in the OS start-up process as possible and canfor example store either a binary copy or a calculated hash (digest). Asecond snapshot is taken later. If the second snapshot is taken beforeapplying the DRM patch, then the snapshot can be of the entire serviceor just a limited part, such as the preamble. Otherwise, if the secondsnapshot is taken after the DRM patch is applied, then the first andsecond snapshots should be of a portion which is not affected byapplication of the DRM patch. Any subsequent changes to the kernelservice (or its preamble) will result in a detectable difference in thesnapshot copy or digest.

[0131] Depending on the OS, it may or may not be possible for the DRMpatch to detect upstream patches by looking at the kernel service entrypoint and making sure that it is still being redirected to the DRM patch(step 1114). When it is not possible to do this directly, one usefultechnique is to attempt to remove and/or reapply the DRM patch everytime it is predicted it will be used, e.g. when the DRM client sets theguard points on the trusted process, thread and/or window (step 1116).This effectively converts upstream patches into less dangerousdownstream patches and often results in the detection of upstreampatches. For example, installing a file system hook into a hook chainusually returns the address of the previous hook in the chain. If, afterremoval and reapplication of a DRM hook, the returned address is notthat of the DRM hook then the DRM client knows that is has detected anupstream hook and can decide whether or not to deny service.

[0132] Embodiments of the present invention have been described withparticular reference to the examples illustrated. However, it will beappreciated that variations and modifications may be made to theexamples described within the scope of the present invention.

1. A method for controlling access by use of an operating system serviceto content that is to be protected from unauthorised access, the methodcomprising the step of: for an operating system service which can enableunauthorised access to protected content, modifying the operation ofsaid operating system service to restrict or deny access to theprotected content.
 2. A method according to claim 1, wherein the step ofmodifying the operation of said operating system service comprises thesteps of: obtaining an address of an entry point of the operating systemservice, and placing, starting at the entry point address, aninstruction such that, when the instruction is executed, substitute codeis executed, the substitute code operating to restrict or deny access tothe protected content.
 3. A method according to claim 2, wherein theinstruction is a jump instruction.
 4. A method according to claim 2 orclaim 3, comprising the step of, after the substitute code is executed,returning the operating system service to its unmodified state.
 5. Amethod according to claim 4, wherein the step of modifying the operationof said operating system service comprises the step of, prior to placingof the instruction, copying to a buffer a service preamble starting atthe entry point address and wherein the step of returning the operatingsystem service to its unmodified state includes the steps of restoringthe service preamble that was copied to the buffer to its originalposition at the entry point address and returning control to the entrypoint address.
 6. A method according to claim 4, wherein the step ofmodifying the operation of said operating system service comprises thestep of, prior to placing of the instruction, copying to a buffer aservice preamble starting at the entry point address and wherein thestep of returning the operating system service to its unmodified stateincludes the steps of executing the service preamble from the buffer towhich it was copied and then returning control to a point just after theplace from which the service preamble was copied.
 7. A method accordingto claim 1, wherein the step of modifying the operation of saidoperating system service comprises the step of: replacing an address ofan entry point of the operating system service in a trap dispatchertable with an address of an entry point of substitute code, thesubstitute code operating to restrict or deny access to the protectedcontent.
 8. A method according to any of claims 1 to 7, wherein theoperating system service is modified before any application processesare loaded.
 9. A method according to claim 8, wherein an initialisationmodule is loaded before any application processes have been loaded, andwherein the modifying step is based on instructions in theinitialisation module.
 10. A method according to claim 9, wherein theinitialisation module is loaded into every application process.
 11. Amethod according to any of claims 1 to 7, wherein a loadable module hasinitialisation code which when executed causes said modifying step totake place and wherein the loadable module has clean-up code which whenexecuted causes said modifying step to be undone, the method comprisingthe step of loading the loadable module into every running applicationprocess.
 12. A method according to claim 11, wherein the step of loadingthe loadable module is carried out as a result of the execution ofanother operating system service.
 13. A method according to claim 11 orclaim 12, wherein the act of loading the loadable module into a runningapplication process causes the initialisation code to be executed.
 14. Amethod according to any of claims 11 to 13, wherein the act of unloadingthe loadable module from a running application process causes theclean-up code to be executed.
 15. A method according to claim 11,comprising the step of a digital rights management client operating viaan inter-process communication mechanism to cause the loadable module toexecute its initialisation code and clean-up code within the context ofeach running application process.
 16. A method according to claim 11,wherein running of an application process into which the loadable modulehas been loaded calls the loadable module thereby to cause the modifyingstep to be carried out.
 17. A method according to any of claims 1 to 16,wherein the modification of the operating system service protects, fromscreen grabbing, at least a visible area of an image displayed on ascreen.
 18. A method according to any of claims 1 to 17, comprising thestep of implementing a virtual file system that can be used tocommunicate decrypted content to a renderer without exposing thedecrypted content to unauthorised access via a local file system.
 19. Amethod according to claim 18, comprising the steps of: passing to arenderer a filename for a virtual file; requesting by the rendereraccess to the file; and, routing the renderer's access request via thevirtual file system to a buffer containing the protected content.
 20. Amethod according to claim 19, comprising the step of decrypting theprotected content before placing the protected content in the buffer.21. A method according to claim 19, comprising the step of placingencrypted content in the buffer, the modified operating system serviceobtaining a decryption key to decrypt the encrypted content on demand.22. A method according to any of claims 1 to 17, comprising the step ofimplementing a secure file system by which only trusted invocations ofthe operating system are permitted to decrypt encrypted files storedwithin an encrypted portion of the secure file system.
 23. A methodaccording to claim 20, wherein said encrypted portion of the file systemcontains protected content and associated licensing information.
 24. Amethod according to any of claims 1 to 23, comprising the steps of:establishing guard points to indicate which processes, threads, and/orwindows are trusted; and, restricting execution of the operating systemservice only to the trusted processes, threads, and/or windows.
 25. Amethod according to any of claims 1 to 24, wherein operation of theoperating system service is modified by use of a device driver.
 26. Amethod according to any of claims 1 to 24, wherein operation of theoperating system service is modified by use of a file system hook.
 27. Amethod according to any of claims 1 to 24, wherein operation of theoperating system service is modified by use of an installable filesystem module.
 28. A method according to any of claims 1 to 27,comprising the step of inspecting the operating system service for thepresence of a downstream patch or hook.
 29. A method according to claim28, wherein the step of inspecting the operating system service includesthe steps of comparing a snapshot of the operating system service with asnapshot of the operating system service obtained during operatingsystem start-up.
 30. A method according to any of claims 1 to 29,comprising the step of detecting an upstream patch or hook bydetermining whether a patched operating system service entry point stillpoints to substitute code installed by a digital rights managementclient.
 31. A method according to any of claims 1 to 30, comprising thestep of detecting an upstream patch or hook by removing and thenreinstalling a patch installed by a digital rights management client.32. A method for controlling access by use of an operating systemservice to content that is to be protected from unauthorised access, themethod comprising the steps of: running an untrusted applicationroutine; and, prior to the application routine using an operating systemservice that would enable unauthorised access to content which is to beprotected, determining whether use of said operating system servicewould cause said operating system service to access said content and, ifso, restricting or denying the operating system service access to saidcontent.
 33. A method according to claim 32, wherein the step of denyingthe operating system service access to said content comprises the stepsof: obtaining an address of an entry point of the operating systemservice, and placing, starting at the entry point address, aninstruction such that, when the instruction is executed, substitute codeis executed, the substitute code operating to restrict or deny access tothe protected content.
 34. A method according to claim 33, wherein theinstruction is a jump instruction.
 35. A method according to claim 33 orclaim 34, comprising the step of, after the substitute code is executed,returning the operating system service to its unmodified state.
 36. Amethod according to claim 35, wherein the step of modifying theoperation of said operating system service comprises the step of, priorto placing of the instruction, copying to a buffer a service preamblestarting at the entry point address and wherein the step of returningthe operating system service to its unmodified state includes the stepsof restoring the service preamble that was copied to the buffer to itsoriginal position at the entry point address and returning control tothe entry point address.
 37. A method according to claim 35, wherein thestep of modifying the operation of said operating system servicecomprises the step of, prior to placing of the instruction, copying to abuffer a service preamble starting at the entry point address andwherein the step of returning the operating system service to itsunmodified state includes the steps of executing the service preamblefrom the buffer to which it was copied and then returning control to apoint just after the place from which the service preamble was copied.38. A method according to claim 32, wherein the step of denying theoperating system service access to said content comprises the step of:replacing an address of an entry point of the operating system servicein a trap dispatcher table with an address of an entry point ofsubstitute code, the substitute code operating to restrict or denyaccess to the protected content.
 39. A method according to any of claims32 to 38, comprising the step of implementing a virtual file system thatcan be used to communicate decrypted content to a renderer withoutexposing the decrypted content to unauthorised access via a local filesystem.
 40. A method according to claim 39, comprising the steps of:passing to a renderer a filename for a virtual file; requesting by therenderer access to the file; and, routing the access request to a buffercontaining the protected content.
 41. A method according to claim 40,comprising the step of decrypting the protected content before placingthe protected content in the buffer.
 42. A method according to claim 40,comprising the step of placing encrypted content in the buffer, theoperating system service obtaining a decryption key to decrypt theencrypted content on demand.
 43. A method according to any of claims 32to 38, comprising the step of implementing a secure file system by whichonly trusted invocations of the operating system are permitted todecrypt encrypted files stored within an encrypted portion of the securefile system.
 44. A method according to claim 43, wherein said encryptedportion of the file system contains protected content and associatedlicensing information.
 45. A method according to any of claims 32 to 44,comprising the steps of: establishing guard points to indicate whichprocesses, threads, and/or windows are trusted; and, restrictingexecution of the operating system service only to the trusted processes,threads, and/or windows.
 46. A method according to any of claims 32 to45, comprising the step of inspecting the operating system service forthe presence of a downstream patch or hook.
 47. A method according toclaim 46, wherein the step of inspecting the operating system serviceincludes the steps of comparing a snapshot of the operating systemservice with a snapshot of the operating system service obtained duringoperating system start-up.
 48. A method according to any of claims 32 to47, comprising the step of detecting an upstream patch or hook bydetermining whether a patched operating system service entry point stillpoints to substitute code installed by a digital rights managementclient.
 49. A method according to any of claims 32 to 48, comprising thestep of detecting an upstream patch or hook by removing and thenreinstalling a patch installed by a digital rights management client.50. A computer program containing program instructions for causing acomputer to perform a method according to any of claims 1 to
 49. 51. Acomputer program according to claim 50, wherein the computer program isembodied in a digital rights management client.